A communication session may involve a persistent interactive exchange of information between two or more communicating entities (e.g. devices, applications, etc.). A communication session is established at a certain point in time, and torn down at a later point in time based on various circumstances (e.g. after the session times out or when one of the entities decides to terminate the session). A communication session may involve the exchange of multiple messages between entities and may be stateful, meaning that at least one of the communicating entities saves information about the session history in order to be able to maintain the communication session—for example, maintaining session context such as connectivity, registration, security, scheduling, and data that is applicable to the session participants.
Communication sessions may be implemented as part of protocols and services at various layers in a network protocol stack. For example, communication connections/sessions may be established between network nodes at the transport protocol layer (e.g. TCP connection), session protocol layer (e.g. TLS and DTLS sessions), Web transport protocol layer (e.g. HTTP and CoAP sessions), machine-to-machine (M2M)/Internet of Things (IoT) service layer, and at the application layer (e.g., application-specific sessions). The present application relates primarily to features targeting M2M/IoT service layer sessions.
A conventional application session is a communication session between two or more applications that is established and managed by the applications themselves rather than by an underlying communication protocol or service layer. As a result, application sessions can add extra overhead and complexity to applications.
A machine-to-machine (M2M) service layer provides value-added services for M2M type devices and applications. For example, an M2M service layer can support Application Programming Interfaces (APIs) providing applications and devices access to a collection of M2M centric capabilities supported by the service layer. A few examples include security, charging, data management, device management, discovery, provisioning, and connectivity management. These capabilities are made available to applications via APIs which make use of message formats, resource structures and resource representations defined by the M2M service layer.
A M2M service layer session is a communication session that is facilitated by the value-added session management services supported by a M2M service layer. These services can include capabilities such as mechanisms for establishing a service layer session between participants as well as collecting and maintaining context pertinent to the service layer session and its participants. A service layer session can be established between two or more M2M service layer session participants where these participants can be M2M applications and/or M2M service layer instances. At a minimum however, at least one instance of a M2M service layer must participate in the session to function as the facilitator of the service layer session (i.e. provide the necessary service layer session management functionality).
One benefit of M2M service layer sessions is they can be used to offload applications from the burden of having to establish and maintain their own application-based sessions. This is because a M2M service layer session differs from an application session in that, the brunt of the overhead involved with establishing and maintaining the session is offloaded to the M2M service layer such that M2M applications are not burdened with this responsibility. Some examples of overhead that can be offloaded to the service layer can include creation and management of session context such as credentials, identifiers, routing information, discovery information, location, transaction history, and data. Another benefit is a M2M service layer session can be layered on top of one or more underlying transport or access network communication sessions. Some examples include but are not limited to Web transport protocol sessions (e.g. HTTP session), session layer sessions (e.g. TLS session), or transport layer connections (e.g. TCP). This layering allows a M2M service layer session to support persistency with regards to lower layer sessions such that the M2M service layer session can persist and be maintained independent of the setup and tear down of lower layer sessions. For example, a M2M service layer session can persist in spite of its underlying TCP/TLS sessions being repeatedly setup and torn-down which is fairly typical during the course of normal network communication (e.g. due to power saving methods and mobility).
The establishment of a M2M service layer session between session participants may either be initiated as part of the service layer registration process or as a separate process thereafter. Once established, a service layer session can be used to collect and maintain service layer context pertaining to the session participants and the communication that takes place between them. For example, service layer session context such as registration state and security credentials of session participants, subscription criteria and contact information for session participants, session participant data stored in service layer resources, and history of transactions performed by session participants, may be collected and maintained for each session. The termination of a M2M service layer session between session participants can either be initiated as part of the service layer de-registration process or as a separate process performed before de-registration takes place.
Establishment of a service layer session as well as the accumulation of service layer session context during the lifetime of a particular service layer session may involve a significant amount time and effort on behalf of the session participants. Hence, the persistent nature of a service layer session is one of its major value-add differentiators compared to lower layer transport and access network sessions which lack this persistency. A persistent service layer session can be used to maintain service layer session context on behalf of applications such that they do not have to maintain this information themselves. In addition, when a lower layer connection/session is torn down the service layer session context can persist and when the lower layer connection is re-established, this context will still be available to an application. Hence this context can be maintained independent of non-persistent underlying transport sessions. Some examples of service layer session context may include service layer registrations, subscriptions, credentials, identifiers, charging records, routing information, discovery information, location, transaction history, and data for applications.